Scripting Tutorial: CTCP



CTCP is different from regular mIRC events. Regular mIRC events follow the IRC protocol while CTCP has it's own - Client to Client Protocol. Clients don't depend on the IRC servers when they CTCP. CTCP remotes are also slightly different in format from the usual remotes. It's format is:

ctcp (level):(text):(location): (command)

Example: ctcp *:check:?: .notice $nick I don't talk in CTCP.

You'll notice that the ON thing is absent here; everything else is the same. The example script will notice the nick who did a CTCP "check" to you with "I don't talk in CTCP.". If have figured the working of general Remote, CTCP Remote should start to make sense to you instantly.

Next I give a list of examples and explain them later. Till I give the explanations, see if you can make sense out of the examples. If you got them all correct you can be sure you can manage any sort of CTCP Remote.

ctcp *:time:?: notice $nick Sorry, forgot to put on my watch. | halt
ctcp *:ping:#: halt
ctcp *:version:?: msg $comchan($nick,1) $nick CTCP VERSIONed me. I feel violated.
ctcp *:opme:?: if ($nick == %op.001) mode $2 +o $nick | else CTCPREPLY $nick OPME Wrong password!
ctcp *:*:?: $1-


The first example: If someone CTCP TIMEs you the script sends a notice to the nick saying "Sorry, I forgot to put on my watch." And then halts the default mIRC CTCP TIME reply - mIRC won't send you the nick your time.

The second example: If someone CTCP PINGs the channel it halts any response to the event. You don't send any PING reply.

The third example: If someone CTCP VERSIONs you, you message on the first common channel both of you are on "(nick) CTCP VERSIONed me. I feel violated.". You can't halt the default mIRC CTCP VERSION response.

The fourth example: If someone sends you a CTCP message OPME, the script first checks if the nick who messaged you is equal to the variable %op.001. If it's true you OP the person on the channel (the second parameter). Of course you will need to be an OP on that channel. If it returns false you send a CTCP REPLY "Wrong password!".

Wondering how you send a CTCP MESSAGE? Use the CTCP (nick) (message) command. Eg: CTCP TestNick Hello. To send CTCP REPLY, use the command CTCPREPLY (nick) (ctcp message name) (reply message). Eg: CTCPREPLY TestNick HELLO Don't HELLO me!.

The fifth example means "On being CTCPed any text anywhere execute the whole thing from parameter one". This is a potentially dangerous event definition because it allows everyone to access it (since we used *), and they will be able to perform any command they want on your computer. To solve the problem you can use Access Levels or process the code so more before straightaway executing the whole thing.

There's nothing much to explain in CTCP since the logic is the same as the regular Remotes. If you can handle Remotes and understand the way CTCP events work you can easily manage CTCP Remotes too. Next we move on to another different kind of Remote - Raw.


Back | Table of Contents | Raw



Copyright © 2002-2004 SpyderWares.
Feel free to distribute this tutorial in part or whole, just make sure the credits stay intact.

http://spyderwares.com